Skip to content

SEP 5 -- 线上发布流程

Head

  • Author: larry
  • Status: final
  • Type: Standards
  • Created: 2017-07-27

摘要

规范线上发布流程，所有发布都需要灰度。

工程配置调整

local.conf从线上删除，所有的线上配置直接提交到工程代码里去。

日志路径从工程目录中抽离到独立的路径，确保多进程灰度中日志可以连贯。确认日志rotate是否需要调整。

灰度思路

ngnix变量
    测试验证客户（group_test）：发布后做测试验证的group id列表
    例行灰度客户（group_gray）：挑选过的group id列表，变动频率很低，每次都先灰度这些客户
    特殊项目灰度客户（group_project_xxx）：个别项目有特殊的灰度策略，在单独的分支配置group id列表

分支定义
    全量分支：全量放开后的运行分支
    灰度分支：部分客户被路由到的灰度分支

灰度过程
    第一天
        全量分支在port_1正常运行中
        灰度分支
            选择新端口（port_2），启动灰度分支。
            配置group_test客户，开始测试验证、无误后下一步。
            配置group_gray客户，测试验证、无误后下一步。
    group_gray客户在灰度分支上运行一天
    第二天
        全量分支的端口指向port_2
        取消group_gray配置    // 因为所有的量都转向了port_2
        观察port_1端口日志流量，没流量后port_1停服

灰度步骤

正常发布流

  1. 发布准备

    1. 当前处于开发分支。合入master更新、或者rebase，编辑发布配置。（注意：发布完成前不合入master）
    2. 找前端为当前版本修改模板文件里的js文件名，如果这个版本前端模块有修改的话。
    3. 准备发布方案：写清楚变更内容，包括代码、配置等所有可能的变化。
    4. 给发布管理员确认，发布管理员确认后方可进一步发布。

  2. 灰度发布(第一天)

    1. 全量分支在port_1正常运行中。
    2. 在全量分支之外，checkout发布分支作为灰度版本。选择新端口（port_2），启动灰度分支。
    3. 测试验证：配置group_test客户流量到port_2，开始测试验证、无误后下一步。
    4. 部分灰度：配置group_gray客户流量到port_2，测试验证、无误后下一步。

  3. 灰度中（一天时间）

  4. 全量发布（第二天）

    1. 全量分支的端口指向port_2。
    2. 取消group_gray配置。因为所有的量都转向了port_2。
    3. 观察port_1端口日志流量，没流量后port_1停服。

  5. 收尾

    1. 老版本目录增加后缀识别。xxx-last。
    2. 代码合入master，打个tag，release-YY-MM-DD-version-name。

异常回退流

  1. 启动上一个版本的服务。
  2. 测试验证：切验证group到老版本，验证无误继续。
  3. 全量放开：切所有流量过去。

发布目录

  1. 发布目录命名，module/YY-MM-DD-author-version-name，比如station/2017-07-27-larry-fixmebug。
  2. 为上一个版本的目录增加后缀识别。module/YY-MM-DD-author-version-name-last。方便回退。

发布自动化

  1. 短期：手动执行灰度。
  2. 中期：编写脚本自动化，在单机上用双进程灰度。
  3. 长期：日志集中化后，双机灰度。

紧急bug处理策略

在发布自动化脚本完成前，紧急bug暂时不做灰度。

自动化完成后，紧急bug也需要加入灰度，只不过可以走特殊项目灰度的模式，把出bug的客户先灰度过来验证。另外灰度时间不需要那么长，客户验证无问题后就可以立刻全量了。